10.2 Azure RTOS Middleware Support

Azure RTOS is an embedded development suite consisting of ThreadX® as its core, along with extended functionalities provided by components such as GUIX, FileX, USBX, and NetX Duo.

Figure 10-1 depicts Azure RTOS middleware components and their interaction with application and hardware.

Figure 10-1 Azure RTOS Components

10.2.1 Azure RTOS ThreadX

Azure RTOS ThreadX is a high-performance RTOS kernel designed specifically for resource-constrained embedded systems and applications. Azure RTOS ThreadX has picokernel architecture.

Azure RTOS ThreadX provides services such as advanced preemption-threshold scheduling, message passing, communication, synchronization, timer, memory management, and interrupt management, event-chaining, execution profiling, performance metrics, and system event tracing, etc.

Figure 10-2 shows different services and APIs offered by Azure RTOS ThreadX and their interactions with different components in the system.

Figure 10-2 ThreadX Services

For more API details and usage, refer to the Azure RTOS ThreadX User Guide.

10.2.2 NetX Duo

Azure RTOS NetX Duo is an embedded TCP/IP stack specifically tailored for resource-constrained embedded real-time and IoT environments. Along with the core network protocols such as TCP, UDP, ICMP, and IP (version 4 and version 6), NetX Duo supports a large number of additional higher layer protocols (such as HTTP(S), MQTT, FTP, etc.) as add-ons. Additionally, NetX Duo provides a set of add-on protocols to enable secure communications. These implement Transport Layer Security protocols (SSL/TLS/DTLS) and IPsec.

10.2.2.1 NetX Duo Support in Alif Semiconductor RTSS SDK

Figure 10-3 is a high-level representation of different components in the network stack of the Alif Semiconductor RTSS SDK. Note that NetX Duo depends on the functionalities provided by Azure RTOS ThreadX and assumes its existence. For clarity, ThreadX is not shown in the figure.

Figure 10-3 NetX Duo

As shown in Figure 10-3, NetX Duo depends on a network driver to perform various functions, including Ethernet hardware and physical link initialization, packet transmission, packet reception, and status and control of the Ethernet interface. The Alif Semiconductor's NetX Duo network driver interacts with the Ethernet MAC and PHY hardware components to service different requests generated by NetX Duo. Apart from handling various requests generated by NetX Duo, the network driver is also responsible for detection and handling asynchronous events that happen in the physical media. These include packet reception, packet transmission complete events and link status/mode changes, etc. The Alif Semiconductor network driver supports the following performance-centric features:

  • Zero-copy transmission and reception: The driver avoids copying packet data between the buffers used by NetX Duo and the buffers used by the Ethernet DMA hardware. This saves CPU cycles and improves performance considerably.
  • Scatter/Gather packet buffers: The driver is capable of programming the Ethernet DMA hardware to assemble packet payload from multiple discontinuous memory regions in both the TX and RX paths. This enables the application developers to choose and configure the packet sizes in the NetX Duo packet pools as per their needs, without worrying about the MTU of the physical media and the size of the received packets. Note that this feature depends on the NetX Duo packet chaining support.

For more details on NetX Duo APIs and usage, refer to the NetX Duo documentation.

10.2.3 FileX

Azure RTOS FileX is file management system for embedded application. Azure RTOS FileX supports most physical media, including RAM disk, USB, SD card. Azure RTOS FileX supports all of Microsoft’s file formats, including FAT12, FAT16, FAT32, and exFAT.

Various services provided by FileX and interaction with other components are shown in Figure 10-4.

Figure 10-4 FileX Services

For more information about FileX and its services, refer to the FileX User Guide.

10.2.4 GUIX

Azure RTOS GUIX is used for GUI implementation on embedded boards. GUIX is GUI software that can be used for real-time applications. GUIX is an event driven framework and works on events pushed into the GUIX event queue. These events are processed in GUIX thread (same as ThreadX thread).

Input drivers, such as touch screens, require additional GUIX threads. The touch input driver sends touch information into the GUIX thread by sending events into the GUIX event queue.

The framework does require hardware-specific input drivers and hardware-specific graphics drivers.

Figure 10-5 shows the Azure RTOS GUIX interaction with different system components.

Figure 10-5 GUIX

10.2.4.1 Azure RTOS GUIX Studio

Azure RTOS GUIX Studio is UI development environment for the GUIX runtime library. It can be run on a Windows Host machine to design display screens for a project. With GUIX Studio, WYSIWYG screen can be designed for GUIX runtime environment. GUIX Studio generates C code that contains all the necessary UI information and code.

10.2.4.1.1 GUIX Studio Requirements

Minimum requirements for GUIX Studio:

  • Windows XP (or above)
  • 200MB of free RAM
  • 2GB of available hard-disk space
  • Display of 1024p × 768p with 256 colors
10.2.4.1.2 GUIX Studio Constraints

The GUIX Studio UI design tool has several constraints, as follows:

  • A maximum of 4 displays per project
  • A maximum of 100,000 widgets per GUIX Studio project
  • A maximum of 100,000 distinct resources, for example colors, fonts, pixelmaps, strings, etc.

For more details about GUIX studio, refer to the GUIX User Guide.

10.2.5 USBX

USBX is a high-performance USB stack designed for resource-constraint real-time embedded environment. USBX provides support for both Host and Device modes, including device-class support for mass storage, CDC-ACM, CDC-ECM, registration of different callbacks related to class defined in the application, and host requests related to setup and configuration. USBX supports Open Host Controller Interface (OHCI) and Enhanced Host Controller Interface (EHCI).

10.2.5.1 USBX Stack Layout

USBX Stack comprises of three major components: Application, USBX Stack, and Dual-Role controller driver as shown in Figure 10-6.

Figure 10-6 USBX

  • Application: Initialization routines for memory, resource, and USB device-class are part of the application. Callbacks related to device class registers in application. Application utilizes device framework and pass it on USBX Stack. Device framework is divided in the following three categories:
    • Descriptors: Device, Configuration, Interface and Endpoint descriptors. These descriptors hold device-specific information, such as class, configurations, interfaces, and endpoints supported by the device.
    • String: String descriptor. This descriptor holds the manufacturer, product and serial number of the USB device.
    • Language: Language descriptor holds language supported by the device.
  • USBX Stack: USBX Stack is responsible for USB Host and Device-class implementation, memory resourcing, stack initialization, callbacks, data transfer routines, descriptor parsing, buffer management and returning data transfer requests to controller driver. This layer interacts with both the application and the controller driver. The requests made by the USB Host, such as GET_DESCRIPTOR, GET_CONFIGURATION, SET_CONFIGURATION, and SET_ADDRESS for device information and configuration are parsed, the data is stored in a buffer, and finally passed by USBX Stack to driver layer for further processing, such as DMA transactions.
  • Dual-Role controller driver: Driver handles the access to hardware registers, endpoint configurations, interrupt handling, DMA transfers, and FIFO maintenance. Setup/Data requests from the USB host to the slave device are handled by the driver. Depending upon type of interrupt (type of request), the driver takes decision and interacts with framework. In response, the framework provides data to driver, and the driver initiates DMA transactions. Following are few events and interrupts handled by the controller driver:
    • XferNotReady
    • XferComplete
    • XferDataStage
    • XferStatusStage.

10.2.5.2 USBX Support for Ensemble DevKit/AppKit

Figure 10-7 shows a simplified diagram of the USBX.

Figure 10-7 USBX Description

Alif Semiconductor DevKit/AppKit USBX provides support for:

  • CDC-ACM device class, which handles communication class requests on interface 0 using a Control/Interrupt endpoint and CDC-ACM data requests on interface 1 using bulk endpoint.
  • CDC-ACM class initialization, memory resourcing, device framework parsing, and providing a data buffer the driver.
  • TRB creation, DMA transaction initiation, Device and endpoint interrupt handling.

10.2.5.3 USBX Working in Device/Host Mode

In Device mode, USB class registration and stack initialization routines, followed by the device controller initialization routine, are called. The device controller is ready to accept interrupts (SETUP from Host) after configurations related to endpoints and device specific registers. Controller driver gets requests from Host and passes them to the USBX Stack. USBX Stack parses the information and returns back data to driver. Driver initiates DMA transaction on specific endpoint.

In Host mode, Setup packets are created by Host and sent on Control Endpoint 0 OUT/IN once the device controller is ready to accept Setup. Host continues with additional requests and enumerates the device if all the information is passed correctly (see Figure 10-8).

Figure 10-8 USBX Flow Diagram